fix: commit transaction after topology query (fixes #1168)#1169
fix: commit transaction after topology query (fixes #1168)#1169finalchild wants to merge 2 commits intoaws:mainfrom
Conversation
|
Hi @finalchild, I believe the fix for this has been merged already (see here). Are you okay with me closing this PR? |
|
@aaron-congo Hi. I haven't got much time to investigate this issue deeper, but I'm not completely convinced that the released fix prevents the whole class of issue from occurring. What if one calls PreparedStatement.getParameterMetaData while not in a transaction and auto-commit is false? The wrapper would try to update the topology, executing a query, and leave a transaction open. Later, when some state-sensitive method like setReadOnly is called, an error will occur because a transaction is open, while the dev would expect that no transaction should be open. I believe the only complete solution is either closing the transaction later (like my patch), or temporarily turning on auto-commit in the first place. I found this article which explains the behavior of auto-commit, which looks pretty harmless to save and recover later if there is no concurrency issues. |
2 participants
Summary
This PR tries to fix #1168, where
queryForTopologyautomatically fired by FailOverPlugin opens a transaction and never closes, resulting in an unexpected change in the connection state.Description
If the connection doesn't auto-commit and wasn't in a transaction already,
queryForTopologyleaves a new transaction open. We have to either commit or roll back the transaction.Note that this PR is a suggestion merely based on a speculation. I haven't tested that this works, nor do I fully understand the meaning of
this.hostListProviderService.isInTransaction(). Please review and close/edit as you see fit.Additional Reviewers
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.